Voice Response Units (“VRUs”) have existed in the prior art for many years, and are generally defined as robotic systems that automatically interact with one or more persons for the exchange of information and the enhancement of communications. There are numerous enhanced services capable of being provided by a VRU, including voice messaging, automated collect calling, international callback, prepaid & postpaid calling card, store & forward, one number service, find me, follow me, 800/900 service, automated customer service, automated agents or attendants, voice activated dialing, prepaid & postpaid wireless, conferencing, and other such enhanced services.
In the prior art, synchronously switched VRUs were initially connected to the Plain Old Telephone System (“POTS”) network (i.e., the Public Switched Telephone Network (“PSTN”)) via analog interfaces. Although POTS analog connections still exist, the use of digitized voice transmission is becoming increasingly common on the PSTN. Because of the advantages of digitized transmission, a synchronous VRU is now typically connected to the POTS network via a digital interface, as disclosed in co-assigned U.S. Pat. No. 5,818,912, entitled FULLY DIGITAL CALL PROCESSING PLATFORM, by Daniel Hammond, issued Oct. 6, 1998, which application is incorporated herein by reference. An example of such a VRU is shown in FIG. 1, wherein synchronous VRU 100 is digitally connected to PSTN 102 via T1 trunk 104 using a standard Integrated Services Digital Network (“ISDN”) format. Digitized voice signals transmitted over the PSTN normally consume approximately 64 Kilobits-per-second (“Kbps”) of bandwidth when digitized and encoded according to the G.711 compressed format using pulse code modulation (“PCM”) and the standard μ-law or A-law logarithmic algorithms.
Generally, in the prior art, the PSTN was originally designed to be managed and controlled by a single entity, and later developed such that very few entities control the primary switches that make up the network infrastructure. Generally, because control of the network is centered inside the PSTN switches and because the PSTN switches are of a proprietary nature, very little control over the switching mechanisms is available to other entities that do not own the switches in the network. For example, each specific connection made by VRU 100, e.g., to telephone 106a, generally requires its own port and a 64 Kbps channel. If the enhanced service being provided by VRU 100 requires connecting telephone 106a to another device external to VRU 100, for example to telephone 106c, there are limited options available to VRU 100, each with its own tradeoffs as explained below.
First, PSTN 102 may transfer a call via Release Link Trunking (“RLT”) by sending control signals to a switch in the network. For example, a calling party using telephone 106a may wish to call another party at telephone 106c using an 800 calling card service provided by VRU 100. After the calling party enters a Card Number, personal identification number (“PIN”) and the phone number for telephone 106c, VRU 100 verifies the information and then connects the two parties using RLT by placing a second call via PSTN 102 and then connecting the two parties. In using RLT, VRU 100 gives up control of the call to PSTN 102, although VRU 100 may send the customer's card number and PIN or a call identifier to PSTN 102 for tracking purposes.
Generally, a useful and desirable 800 calling card service feature known as call re-origination allows the calling party to disconnect from the called party and reconnect to another called party without breaking the calling party's initial connection. Typically, the calling party on telephone 106a may hold down the # key for more than two seconds to signal to the network the calling party's desire to make a new call, although many other signals and durations may be used. Because VRU 100 has relinquished control of the call to PSTN 102, PSTN 102 must monitor the call for the # key dual-tone multi-frequency (“DTMF”) signal so that PSTN 102 may then reconnect the calling party on telephone 106a to VRU 100. PSTN 102 also sends the customer ID and PIN or call identifier back to VRU 100 so that the customer does not have to reenter this information. This approach has the advantage of freeing up the VRU ports for other callers, but it requires PSTN 102 to have an application running for tracking the customer's ID and PIN, and for monitoring the call for DTMF signals.
Second, a user such as VRU 100 may use a hook flash and redial to request that PSTN 102 directly connect telephone 106a to telephone 106c. This also has the advantage of freeing up ports on VRU 100, but VRU 100 permanently loses the call context. Unlike RLT, the hook flash does not allow VRU 100 to retrieve the call context from PSTN 102. The VRU then cannot perform important call control or administrative functions such as monitoring, recording, timing, or charging for the phone call. Because the call context is lost for VRU 100, the calling party generally must reenter the Card Number and PIN, in addition to the new destination phone number, and VRU 100 must re-verify the calling party's information. Reentering these numbers can be frustrating to customers, and consumes extra connection time and processing resources.
Alternatively, the connection between the two parties may be bridged between the telephones within VRU 100. Internal synchronous switch 112 and another port and 64 Kbps channel are required to complete the connection to telephone 106c. VRU 100 does not relinquish control of the call to PSTN 102, so VRU 100 may still perform call control and administrative functions. In addition, VRU 100 may monitor the call for DTMF signals. If the calling party using an 800 calling card service wishes to make another call, the calling party may hold the # key for more than two seconds. VRU 100 detects this signal directly, and can disconnect the called party on one port from the calling party on the other port. Because VRU 100 maintained the call context, the calling party's Card Number and PIN do not have to be reentered and re-verified. The calling party may simply enter the new destination phone number, and VRU 100 may then set up a new connection using another port. However, this alternative requires VRU 100 to implement internal switch 112, and uses two circuits in the network and two ports on VRU 100, one for each party. Thus the VRU ports generally stay engaged for the entire duration of the phone call, instead of being made available for use on other phone calls. This is undesirable because unlike a simple switch, VRU ports are generally expensive resources that provide enhanced functions, such as voice recognition, DTMF detection/generation or text-to-speech conversion, for interacting with callers. Normally, the network owners would like to always keep the VRU port busy handling new calls. However, since the VRU ports are used to access the internal switch, the VRU ports are engaged during the entire call, even though the port is idle.
In addition to internal switch 112 and extra network bandwidth used, a VRU bridged connection may also travel over an inordinate amount of distance. For example, a calling party in Houston, Tex., may wish to call another party in New Orleans, Lo., using an 800 calling card service provided by a VRU. If the VRU is located in either of those cities, then the bridged call does not travel much extra distance compared to the physical distance between the actual parties. If the VRU is located in Los Angeles, Calif., however, the inbound call to the VRU must travel all the way to Los Angeles from Houston, and the outbound call from the VRU must travel all the way to New Orleans from Los Angeles, which is an inefficient use of network resources.
Other problems with synchronously switched networks exist. They generally are expensive to build, difficult to upgrade once built, and not flexible enough to support new multimedia services. In response to these difficulties, along with other factors, there has been a dramatic increase in recent years of the availability of public packet networks, such as the Internet, other wide area networks (“WANs”), and local area networks (“LANs”), to exchange information, for example, in voice format. PSTN circuits generally multiplex digitized voice signals by allocating sequential bits or words in separate conversations to periodic time slots in a time division multiple access (“TDMA”) structure. The PSTN requires a switched architecture and point-to-point connections, and the data is transmitted continuously, so PSTN connections use up bandwidth needlessly when voices are silent during a call. On the other hand, packet networks asynchronously send digitized signals in packetized form, where each packet is encoded with a header that references its destination and sequence. The packets are only sent when there is information to send, thus packet networks do not need to send packets when the callers' voices are silent, saving bandwidth.
In a packet network, the packets may follow one of many possible pathways to their destinations before they are reassembled, according to their headers, into a conversation. Generally, this has the disadvantage over the POTS/TDMA method in that the packet headers consume additional bandwidth. The packet header disadvantage is generally believed to be outweighed by the efficiencies in network usage without switched architecture and point-to-point connections because, for example, a synchronous network continuously uses the same bandwidth even if there is no substantive signal to transmit.
In part to promote interoperability in the fast developing packet network technology area, the International Telecommunications Union (“ITU”), located in Geneva, Switzerland and with a World Wide Web (“WWW”) site of “http://www.itu.org,” has developed the H.323 standard for real-time multimedia (defined herein as including voice, video, data, or any combination thereof) communications and conferencing for packet-based networks. The H.323 standard, entitled “Packet-based Multimedia Communications Systems,” released February 1998, is incorporated herein by reference, and is actually an umbrella standard for a series of specifications that describe how multimedia communications occur between terminals, network equipment and services on packet networks (e.g., Internet Protocol (“IP”) networks), some of which do not provide a guaranteed Quality of Service (“QoS”). The standard is based on the Internet Engineering Task Force (“IETF”) real-time transport protocol (“RTP”) and real-time transport control protocol (“RTCP”), with additional protocols for call signaling and data and audiovisual communications. Another protocol, the resource reservation protocol (“RSVP”), may be implemented in routers to establish and maintain requested transmission paths and QoS levels. Generally, a protocol that guarantees a QoS level has mechanisms for ensuring the on-time delivery of traffic signals, recovering lost packets, and guaranteeing bandwidth availability for specific applications.
Some of the specifications referenced by the H.323 standard include call control and framing specifications, such as H.225, Q.931, and H.245, audio codec specifications, such as G.711 for high bit rate connections and G.723 for low-bit-rate connections, video codec specifications, such as H.261 for high bit rate connections and H.263 for low-bit-rate connections, and data communications specifications, such as T.120 standards. The H.323 standard defines several entities that may exist on a packet network: terminals, Multipoint Control Units (“MCUs”), gatekeepers, and gateways. Terminals support at least voice communications and optionally support multimedia communications, and include such components as personal computers and IP phones with at least voice capability and optionally multimedia capability. MCUs support conferencing for three or more network endpoints. Gatekeepers provide network management and virtual Private Branch Exchange (“PBX”)-type capabilities, such as call control services like address translation for network endpoints. Gateways support at least voice and optionally multimedia inter-networking for connecting IP packet-based networks with circuit-switched networks, and provide translations between different transmission formats, communications procedures, and codecs.
A synchronous VRU may interface with an asynchronous packet network via a PSTN/packet gateway. A PSTN/packet gateway converts TDMA voice signals received, for example, over a standard PSTN line, into packetized voice signals, and vice versa, and allows the resources in the PSTN network to exchange information with resources in the packet network. Generally, the PSTN/packet gateway also performs conversion of analog signals to digital signals (if required), or accepts the μ-law encoded digital signals directly from the PSTN. The gateway may optionally compress the digitized signals from μ-law (about 64 Kbps) down to as low as about 5 Kbps before packetizing (and vice versa). The packetized voice signals may be multiplexed with numerous other signals for transmission over a data line. A typical application of such a PSTN/packet gateway is providing an alternative to making a long distance call. Instead of making a long distance connection where the network uses digital TDMA lines at approximately 64 Kbps of bandwidth per call, callers may make a local POTS call to a PSTN/packet gateway. The gateway may digitize, if necessary, and optionally compress the incoming signal down to about 5 or 6 Kbps. The gateway then packetizes the signal. These packetized signals may then be multiplexed and routed in bulk very cheaply over long distances on a data grade network. At the other end, another PSTN/packet gateway receives and reassembles the packetized signal, and then decompresses the signal, if necessary, and converts it back into a TDMA-multiplexed signal. Resources at the distant gateway then make another local POTS call to complete the connection between the calling party and the receiving party.
A synchronous VRU connected to a PSTN/packet gateway may provide the enhanced services described above, and take advantage of the additional capabilities of the packet network. Such a system is one of the systems discussed in co-assigned, co-pending patent application Ser. No. 08/719,163, entitled INTERACTIVE INFORMATION TRANSACTION PROCESSING SYSTEM WITH UNIVERSAL TELEPHONY GATEWAY CAPABILITIES, by Michael Polcyn, filed Sep. 24, 1996. An example of such a system is shown in FIG. 2. As discussed in application Ser. No. 08/719,163, the VRU (i.e., Interactive Voice Response Unit (“IVR”)) may be an automated voice resource known in the art, such as the “OneVoice” or “IN*Control” platforms, available from InterVoice, Inc., 17811 Waterview Parkway, Dallas, Tex., 75252. Ports on the VRU receive individual communications, and resources in the VRU perform processing to make communications in one format (e.g., asynchronous data in the packet network) understandable to communications in other formats (e.g. synchronous data in the POTS network).
In the example system shown in FIG. 2, synchronous VRU 200 connects to PSTN 202 via T1 trunk 204, as in FIG. 1. In addition, VRU 200 connects to PSTN/packet gateway 214 via T1 trunk 212, and gateway 214 is connected asynchronously to packet network 216. If telephone 218 is physically located in a different area than VRU 200, access to VRU 200 via the POTS network may require a long distance phone call. To reduce the cost of this connection, telephone 218 may access PSTN 220, which in turn provides a synchronous connection to gateway 224 via T1 trunk 222. Because data in PSTN 220 is in G.711 format, gateway 224 may translate the data into G.723 compressed format for transmission over asynchronous packet network 216, or gateway 224 may leave the data in G.711 format and not change the compression format for transmission over packet network 216. Gateway 224 also provides the appropriate headers for routing the packets to gateway 214. Gateway 214 may then decompress the reassembled packets, if necessary, from G.723 format and translate the data into G.711 format for transmission to VRU 200 over T1 trunk 212. As with the system in FIG. 1, each specific connection made by VRU 200 generally requires a port and a 64 Kbps channel on T1 trunk 212. If the enhanced service being provided by VRU 200 requires connecting telephone 218 to another device external to VRU 200, for example to telephone 206 or telephone 232, then internal synchronous switch 238 and another port and 64 Kbps channel are required to complete the connection. In addition, if the connection to the external device is back through gateway 214 and packet network 216, the entire sequence of compression/decompression, if necessary, and translation must be performed again.